In contemporary computing networks, network administrators define policies for users and computer systems of that network. With a Microsoft Windows®-based operating system, administrators use Group Policy technology to define the state of users' work environment, and rely on the system to enforce the defined policies. In general, those policies are then applied to determine how the various computer systems are configured. For example, the configuration that a user sees when logged onto any computer system of the network depends on the policy settings for that machine combination with the policy settings for that user.
In such a network, Group Policy can be used to specify many of the settings for a user and computer, including registry-based policy settings used to configure and specify behavior of the operating system and optionally application programs based on settings in various computer systems' registries, and script-related policy settings control scripts for computer startup and shutdown, and user logon and logoff. Group policy can also specify particular software programs for groups of users and/or machines, as Group Policy includes settings for centrally managing the installation, updates, and removal of application programs and components. Security options are also provided by policy settings, e.g., for local computer, domain, and network security settings. Folder redirection options, which allow administrators to redirect users' special folders to the network, also may be managed via Group Policy, as can Internet Explorer Maintenance, which is used to manage settings related to Internet Explorer and Remote Installation Services options, which are used to manage client configuration options that users see when performing Remote Installation Services-based installs. Internet Protocol Security Settings and Wireless settings can also be deployed through Group Policy, and public key policy settings, as well as software restriction policies can also be managed.
To apply and enforce the policy in a Windows®-based operating system, the Group Policy settings that administrators create are contained in group policy objects (GPOs), which in turn are applied to one or more scopes of management, such as a site, domain, or organizational unit (OU) in Active Directory®. A site, domain, or organizational unit may also be referred to as a scope of management, or SOM. In this manner, administrators centrally apply policy to users and computers of those sites, domains, and organizational units. Policy settings from each of these different hierarchical levels are combined and applied to the policy recipients. Any conflicting policy among the levels is resolved via various rules, as generally described in U.S. Pat. No. 6,466,932, herein incorporated by reference.
While Group Policy thus greatly simplifies network administration, group policy objects are not simple objects, but rather virtual objects comprising complex pieces of setting definitions that are stored on the domain, e.g., in an Active Directory® service objects and attributes and in file system (sysvol) files. In general, each group policy object comprises multiple subcomponents, typically including a collection of many files, other objects and attributes, that reference one another in various ways. Although the creation of a group policy object is facilitated by software tools, because of the many complex settings and interrelationships, each group policy object still may take many hours to configure and test, before that group policy object can be deployed on a production domain.
However, deployment itself is not straightforward, as due to a number of factors, there have heretofore been only very limited ways to implement operations on a group policy object, once created. For example, some of the settings in a group policy object may be specific to the domain in which that group policy object resides. For such domain-specific group policy objects, is thus virtually impossible to use them on a different domain and obtain the same effect, since many of the settings would be irrelevant, while others might cause substantial errors, including potential security problems. At the same time, deploying a group policy object on a domain without testing it is dangerous, and thus administrators need to create a group policy object, test it on a test domain making adjustments as necessary, and then re-create the group policy objects with appropriate modifications for a production domain. This is time-consuming and error prone; what is needed is a better way to operate on group policy objects.